Lecture 5
Next-up
Joon Yoo
October 5, 2018
Multimedia: video
video: sequence of images displayed at
constant rate
e.g., 24 images/sec
digital image: array of pixels
each pixel represented by bits
coding: use redundancy within and
between images to decrease # bits
used to encode image
spatial (within image)
temporal (from one image to next)
- 2
……………………..
spatial coding example: instead
of sending N values of same
color (all purple), send only two
values: color value (purple) and
number of repeated values (N)
……………….…….
frame i
frame i+1
temporal coding example:
instead of sending
complete frame at i+1,
send only differences from
frame i
Streaming stored video:
simple scenario:
- 3
video server
(stored video)
client
Internet
streaming stored audio, video
streaming: can begin playout before downloading entire file
stored (at server): can transmit faster than audio/video will be rendered (implies
storing/buffering at client)
e.g., YouTube, NetFlix, Vimeo, …
Streaming multimedia: HTTP
multimedia file retrieved via HTTP GET (Same as Web!)
send at maximum possible rate under TCP
Buffer fill rate fluctuates due to TCP congestion control, retransmissions (in-order delivery)
Use application playout buffer: larger playout delay - smooth application playout
Examples: Youtube, Netflix, and most streaming applications…
- 4
variable
rate, x(t)
TCP send
buffer
video
file
TCP receive
buffer
application
playout buffer
server
client
Why HTTP (TCP)?
UDP vs. TCP
UDP: unreliable (no acks), lightweight (faster), smooth
TCP: reliable (use acks), heavyweight (slower), sawtooth pattern (congestion control)
UDP was used mainly for multimedia streaming
But UDP traffic is blocked at firewalls security issue
Need separate servers for Video streaming
Why HTTP (TCP)?
HTTP/TCP passes more easily through firewalls (UDP cannot)
Can utilize existing Web servers (can be used for both Web and Video streaming)
TCP sawtooth pattern can be smoothened by application buffer
- 5
DASH: Dynamic, Adaptive Streaming over HTTP
server:
divides video file into multiple chunks
each chunk is 1~15 seconds of video data
each chunk stored, encoded at different rates
client:
periodically measures server-to-client bandwidth
chooses maximum coding rate sustainable given current bandwidth
can choose different coding rates at different points in time (depending on
available bandwidth at time)
Examples: MPEG-DASH, Adobe, Apple, MS, …
- 6
720p
360p
240p
DASH: Dynamic, Adaptive Streaming over HTTP
- 7
http://en.wikipedia.org/wiki/Adaptive_bitrate_streaming
Next-up
MP-DASH: Adaptive Video Streaming Over Preference-Aware Multipath,
CoNEXT'16
Multipath TCP + DASH = MP-DASH
Main Goal: Enhance MPTCP to support adaptive video streaming (DASH)
Example: Use less cellular data (=less money) with negligible degradation of QoE
Motivations
Multipath TCP
Path selection in MPTCP is defined by MPTCP scheduler: select the smallest RTT path
Measurement Study in the Wild
Can Wi-Fi alone support 1080p video? 3 scenarios:
1) Wi-Fi only is never able to support 1080p (64%)
2) Wi-Fi can sometimes play 1080p, but not always (15%)
3) Wi-Fi can almost always stably support 1080p (21%)
79% of the time Wi-Fi is poor: Wi-Fi alone cannot always support 1080p
MPTCP can be helpful... increases throughput better QoE!
21% of time Wi-Fi alone is enough (next slide)
Motivations
21% of time Wi-Fi alone is enough (continued)
MPTCP can use unnecessary use LTE bandwidth
Example: 1080p needs 4Mbps, current Wi-Fi 12.1Mbps,
LTE 14.6Mbps MPTCP still uses LTE!
Controlled Experiments
Observation 1: LTE link is almost always used even
though we need only 0.2Mbps LTE for 1080p
Observation 2: After finishing downloading a chunk,
networks will be idle. This means enough video
chunks in receiver buffer.
QoE will not be affected if chunks arrive a bit late, as long
as playback deadline is met